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Status of this Memo 


This RFC specifes an IAB standards track protocol for the 
Internet community, and requests discussion and suggestions 
for improvements. Please refer to the current edition of the 
"IAB Official Protocol Standards" for the standardization 
state and status of this protocol. Distribution of this memo 
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1. Introduction 


A network management system contains: several (potentially 
many) nodes, each with a processing entity, termed an agent, 
which has access to management instrumentation; at least one 
management station; and, a management protocol, used to convey 
management information between the agents and management 
stations. Operations of the protocol are carried out under an 
administrative framework which defines both authentication and 
authorization policies. 


Network management stations execute management applications 
which monitor and control network elements. Network elements 
are devices such as hosts, routers, terminal servers, etc., 
which are monitored and controlled through access to their 
management information. 


The management protocol, version 2 of the Simple Network 
Management Protocol [1], may be used over a variety of 
protocol suites. It is the purpose of this document to define 
how the SNMPv2 maps onto an initial set of transport domains. 
Other mappings may be defined in the future. 


Although several mappings are defined, the mapping onto UDP is 
the preferred mapping. As such, to provide for the greatest 
level of interoperability, systems which choose to deploy 
other mappings should also provide for proxy service to the 
UDP mapping. 


1.1. A Note on Terminology 


For the purpose of exposition, the original Internet-standard 
Network Management Framework, as described in RFCs 1155, 1157, 
and 1212, is termed the SNMP version 1 framework (SNMPvl). 

The current framework is termed the SNMP version 2 framework 
(SNMPv2) . 
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2. Definitions 
SNMPv2-TM DEFINITIONS ::= BEGIN 


IMPORTS 
snmpDomains, snmpProxys 
FROM SNMPv2-SMI 
TEXTUAL-CONVENTION 
FROM SNMPv2-TC; 


-— SNMPv2 over UDP 


snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 } 
-- for a SnmpUDPAddress of length 6: 


== octets contents encoding 
== -1=4 IP-address network-byte order 
== 6 UDP-port network-byte order 
SnmpUDPAddress ::= TEXTUAL-CONVENTION 

DISPLAY-HINT "1d.1d.1d.1d/2d" 

STATUS current 

DESCRIPTION 

"Represents a UDP address." 
SYNTAX OCTET STRING (SIZE (6)) 


1993 
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--— SNMPv2 over OSI 


snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 } 
snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 } 
-- for a SnmpOSIAddress of length m: 


= 0CTEES contents encoding 
=- 1 length of NSAP "n" as an unsigned-integer 
=: (either 0 or from 3 to 20) 
== 2..(n+1) NSAP concrete binary representation 
—- (n+2)..m TSEL string of (up to 64) octets 
SnmpOSIAddress ::= TEXTUAL-CONVENTION 

DISPLAY-HINT "*1x:/1x:" 

STATUS current 

DESCRIPTION 

"Represents an OSI transport-address." 
SYNTAX OCTET STRING (SIZE (1 | 4..85)) 
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-—-— SNMPv2 over DDP 


snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 } 
-- for a SnmpNBPAddress of length m: 


== octets contents encoding 

S 1 length of object "n" as an unsigned integer 
=- 2-5 nel) object string of (up to 32) octets 
=: n+2 length of type "p" as an unsigned integer 
=- (n+3)..(n+2+p) type string of (up to 32) octets 
== n+3+p length of zone "q" as an unsigned integer 
=- (n+4+p)..m zone string of (up to 32) octets 


-- for comparison purposes, strings are Case-insensitive 


-=- all strings may contain any octet other than 255 (hex ff) 


SnmpNBPAddress ::= TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 
"Represents an NBP name." 
SYNTAX OCTET STRING (SIZE (3..99)) 


-—-— SNMPv2 over IPX 


snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 } 
-- for a SnmpIPXAddress of length 12: 


== octets contents encoding 
== 1-4 network-number network-byte order 
== ~$=10 physical-address network-byte order 
== 11-12 socket-number network-byte order 
SnmpIPXAddress ::= TEXTUAL-CONVENTION 

DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 

STATUS current 

DESCRIPTION 

"Represents an IPX address." 
SYNTAX OCTET STRING (SIZE (12)) 
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-- for proxy to community-based SNMPv1 (RFC 1157) 


rfcl1157Proxy OBJECT IDENTIFIER { snmpProxys 1 } 


-- uses SnmpUDPAddress 
rfc1157Domain OBJECT IDENTIFIER 


ll 
~ 


rfcl1157Proxy 1 } 


-- the community-based noAuth 
rfcl157noAuth OBJECT IDENTIFIER 


ll 
a 


rfcl157Proxy 2 } 


END 
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3. SNMPv2 over UDP 


This is the preferred transport mapping. 


3.1. Serialization 


Each instance of a message is serialized onto a single UDP[2] 
datagram, using the algorithm specified in Section 8. 


3.2. Well-known Values 


Although the partyTable gives transport addressing information 
for an SNMPv2 party, it is suggested that administrators 
configure their SNMPv2 entities acting in an agent role to 
listen on UDP port 161. Further, it is suggested that 
notification sinks be configured to listen on UDP port 162. 


The partyTable also lists the maximum message size which a 
SNMPv2 party is willing to accept. This value must be at 
least 484 octets. Implementation of larger values is 
encouraged whenever possible. 
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4. SNMPv2 over OSI 


This is an optional transport mapping. 


4.1. Serialization 


Each instance of a message is serialized onto a single TSDU 
[3,4] for the OSI Connectionless-mode Transport Service 
(CLTS), using the algorithm specified in Section 8. 


4.2. Well-known Values 


Although the partyTable gives transport addressing information 
for an SNMPv2 party, it is suggested that administrators 
configure their SNMPv2 entities acting in an agent role to 
listen on transport selector "snmp-1" (which consists of six 
ASCII characters), when using a CL-mode network service to 
realize the CLTS. Further, it is suggested that notification 
sinks be configured to listen on transport selector "snmpt-1" 
(which consists of seven ASCII characters) when using a CL- 


mode network service to realize the CLTS. Similarly, when 
using a CO-mode network service to realize the CLTS, the 
suggested transport selectors are "snmp-o" and "snmpt-o", for 


agent and notification sink, respectively. 


The partyTable also lists the maximum message size which a 
SNMPv2 party is willing to accept. This value must be at 
least 484 octets. Implementation of larger values is 
encouraged whenever possible. 
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5. SNMPv2 over DDP 


This is an optional transport mapping. 


5.1. Serialization 


Each instance of a message is serialized onto a single DDP 
datagram [5], using the algorithm specified in Section 8. 


5.2. Well-known Values 


SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 
entities acting in an agent role listens on DDP socket number 
8, whilst notification sinks listen on DDP socket number 9. 


Although the partyTable gives transport addressing information 
for an SNMPv2 party, administrators must configure their 
SNMPv2 entities acting in an agent role to use NBP type "SNMP 
Agent" (which consists of ten ASCII characters), whilst 
notification sinks must be configured to use NBP type "SNMP 
Trap Handler" (which consists of seventeen ASCII characters). 


The NBP name for agents and notification sinks should be 
stable - NBP names should not change any more often than the 
IP address of a typical TCP/IP node. It is suggested that the 
NBP name be stored in some form of stable storage. 


The partyTable also lists the maximum message size which a 
SNMPv2 party is willing to accept. This value must be at 
least 484 octets. Implementation of larger values is 
encouraged whenever possible. 


5.3. Discussion of AppleTalk Addressing 


The AppleTalk protocol suite has certain features not manifest 
in the TCP/IP suite. AppleTalk’s naming strategy and the 
dynamic nature of address assignment can cause problems for 
SNMPv2 entities that wish to manage AppleTalk networks. 

TCP/IP nodes have an associated IP address which distinguishes 
each from the other. In contrast, AppleTalk nodes generally 
have no such characteristic. The network-level address, while 
often relatively stable, can change at every reboot (or more 
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frequently). 


Thus, when SNMPv2 is mapped over DDP, nodes are identified by 
a "name", rather than by an "address". Hence, all AppleTalk 
nodes that implement this mapping are required to respond to 
NBP lookups and confirms (e.g., implement the NBP protocol 
stub), which guarantees that a mapping from NBP name to DDP 
address will be possible. 


In determining the SNMP identity to register for an SNMPv2 
entity, it is suggested that the SNMP identity be a name which 
is associated with other network services offered by the 
machine. 


NBP lookups, which are used to map NBP names into DDP 
addresses, Can Cause large amounts of network traffic as well 
as consume CPU resources. It is also the case that the 
ability to perform an NBP lookup is sensitive to certain 
network disruptions (such as zone table inconsistencies) which 
would not prevent direct AppleTalk communications between two 
SNMPv2 entities. 


Thus, it is recommended that NBP lookups be used infrequently, 
primarily to create a cache of name-to-address mappings. 

These cached mappings should then be used for any further SNMP 
traffic. It is recommended that SNMPv2 entities acting in a 
manager role should maintain this cache between reboots. This 
caching Can help minimize network traffic, reduce CPU load on 
the network, and allow for (some amount of) network trouble 
shooting when the basic name-to-address translation mechanism 
is broken. 


5.3.1. How to Acquire NBP names 


An SNMPv2 entity acting in a manager role may have a pre- 
configured list of names of "known" SNMPv2 entities acting in 
an agent role. Similarly, an SNMPv2 entity acting in a 
manager role might interact with an operator. Finally, an 
SNMPv2 entity acting in a manager role might communicate with 
all SNMPv2 entities acting in an agent role in a set of zones 
or networks. 
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5.3.2. When to Turn NBP names into DDP addresses 


When an SNMPv2 entity uses a cache entry to address an SNMP 
packet, it should attempt to confirm the validity mapping, if 
the mapping hasn't been confirmed within the last T1 seconds. 
This cache entry lifetime, Tl, has a minimum, default value of 
60 seconds, and should be configurable. 


An SNMPv2 entity acting in a manager role may decide to prime 
its cache of names prior to actually communicating with 
another SNMPv2 entity. In general, it is expected that such 
an entity may want to keep certain mappings "more current" 
than other mappings, e.g., those nodes which represent the 
network infrastructure (e.g., routers) may be deemed "more 
important". 


Note that an SNMPv2 entity acting in a manager role should not 
prime its entire cache upon initialization - rather, it should 
attempt resolutions over an extended period of time (perhaps 
in some pre-determined or configured priority order). Each of 
these resolutions might, in fact, be a wildcard lookup in a 
given zone. 


An SNMPv2 entity acting in an agent role must never prime its 
cache. Such an entity should do NBP lookups (or confirms) 
only when it needs to send an SNMP trap. When generating a 
response, such an entity does not need to confirm a cache 
entry. 


5.3.3. How to Turn NBP names into DDP addresses 


If the only piece of information available is the NBP name, 
then an NBP lookup should be performed to turn that name into 
a DDP address. However, if there is a piece of stale 
information, it can be used as a hint to perform an NBP 
confirm (which sends a unicast to the network address which is 
presumed to be the target of the name lookup) to see if the 
stale information is, in fact, still valid. 


An NBP name to DDP address mapping can also be confirmed 
implicitly using only SNMP transactions. For example, an 
SNMPv2 entity acting in a manager role issuing a retrieval 
operation could also retrieve the relevant objects from the 
NBP group [6] for the SNMPv2 entity acting in an agent role. 
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This information can then be correlated with the source DDP 
address of the response. 


5.3.4. What if NBP is broken 


Under some circumstances, there may be connectivity between 
two SNMPv2 entities, but the NBP mapping machinery may be 
broken, e.g., 


O the NBP FwdReg (forward NBP lookup onto local attached 
network) mechanism might be broken at a router on the 
other entity's network; or, 


O the NBP BrRq (NBP broadcast request) mechanism might be 
broken at a router on the entity's own network; or, 


O NBP might be broken on the other entity's node. 


An SNMPv2 entity acting in a manager role which is dedicated 
to AppleTalk management might choose to alleviate some of 
these failures by directly implementing the router portion of 
NBP. For example, such an entity might already know all the 
zones on the AppleTalk internet and the networks on which each 
zone appears. Given an NBP lookup which fails, the entity 
could send an NBP FwdReq to the network in which the agent was 
last located. If that failed, the station could then send an 
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to 
each network number on that network. Of the above (single) 
failures, this combined approach will solve the case where 
either the local router’s BrRq-to-FwdReq mechanism is broken 
or the remote routers FwdReg-to-LkUp mechanism is broken. 
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6. SNMPv2 over IPX 


This is an optional transport mapping. 


6.1. Serialization 


Each instance of a message is serialized onto a single IPX 
datagram [7], using the algorithm specified in Section 8. 


6.2. Well-known Values 


SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet 
Exchange Packet). 


Although the partyTable gives transport addressing information 
for an SNMPv2 party, it is suggested that administrators 
configure their SNMPv2 entities acting in an agent role to 
listen on IPX socket 36879 (900f hexadecimal). Further, it is 
suggested that notification sinks be configured to listen on 
IPX socket 36880 (9010 hexadecimal) 


The partyTable also lists the maximum message size which a 
SNMPv2 party is willing to accept. This value must be at 
least 546 octets. Implementation of larger values is 
encouraged whenever possible. 
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7. Proxy to SNMPv1 


In order to provide proxy to community-based SNMP [8], some 
definitions are necessary for both transport domains and 
authentication protocols. 


7.1. Transport Domain: rfcl1157Domain 


The transport domain, rfcl1157Domain, indicates the transport 
mapping for community-based SNMP messages defined in RFC 1157. 
When a party’s transport domain (partyTDomain) is 
rfc1157Domain: 


(1) the party's transport address (partyTAddress) shall be 6 
octets long, the initial 4 octets containing the IP- 
address in network-byte order, and the last two octets 
containing the UDP port in network-byte order; and, 


(2) the party's authentication protocol (partyAuthProtocol) 
shall be rfcl1157noAuth. 


When a proxy relationship identifies a proxy destination party 
which has rfcl157Domain as its transport domain: 


(1) the proxy source party (contextSrcPartyIndex) and proxy 
context (contextProxyContext) components of the proxy 
relationship are irrelevant; and, 


(2) Section 3.1 of [9] specifies the behavior of the proxy 
agent. 


7.2. Authentication Algorithm: rfc1157noAuth 


A party’s authentication protocol (partyAuthProtocol) 
specifies the protocol and mechanism by which the party 
authenticates the integrity and origin of the SNMPvl or SNMPv2 
PDUs it generates. When a party’s authentication protocol is 
rfc1157noAuth: 


(1) the party's public authentication key (partyAuthPublic), 


clock (partyAuthClock), and lifetime (partyAuthLifetime) 
are irrelevant; and, 
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(2) the party’s private authentication key 
(partySecretsAuthPrivate) shall be used as the 1157 
community for the proxy destination, and shall be at 
least one octet in length. (No maximum length is 
specified.) 


Note that when setting the party's private authentication key, 
the exclusive-OR semantics specified in [10] still apply. 
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8. Serialization using the Basic Encoding Rules 


When 


(1) 


the Basic Encoding Rules [11] are used for serialization: 


When encoding the length field, only the definite form is 
used; use of the indefinite form encoding is prohibited. 
Note that when using the definite-long form, it is 
permissible to use more than the minimum number of length 
octets necessary to encode the length field. 


When encoding the value field, the primitive form shall 
be used for all simple types, i.e., INTEGER, OCTET 
STRING, OBJECT IDENTIFIER, and BIT STRING (either 
IMPLICIT or explicit). The constructed form of encoding 
shall be used only for structured types, i.e., a SEQUENCE 
or an IMPLICIT SEQUENCE. 


When a BIT STRING is serialized, all named-bits are 
transferred regardless of their truth-value. Further, if 
the number of named-bits is not an integral multiple of 
eight, then the fewest number of additional zero-valued 
bits are transferred so that an integral multiple of 
eight bits is transferred. 


These restrictions apply to all aspects of ASN.1 encoding, 
including the message wrappers, protocol data units, and the 


data 


Case, 


objects they contain. 
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8.1. Usage Example 


As an example of applying the Basic Encoding Rules, suppose 
one wanted to encode an instance of the GetBulkRequest-PDU 


LIJ: 


[5] IMPLICIT SEQUENCE { 


request-id 1414684022, 


non-repeaters 1, 
max-repetitions 2, 
variable-bindings 


{ name sysUpTime, 


{ 


value { unspecified NULL } }, 
{ name ipNetToMediaPhysAddress, 

value { unspecified NULL } }, 
{ name ipNetToMediaType, 

value { unspecified NULL } ) 


} 


Applying the BER, this would be encoded 


[5] IMPLICIT SEQUENCE 
INTEGER 
INTEGER 
INTEGER 
SEQUENCE 
SEQUENCE 
OBJECT IDENTIFIER 
NULL 
SEQUENCE 
OBJECT IDENTIFIER 
NULL 
SEQUENCE 
OBJECT IDENTIFIER 
NULL 


Note that the initial SEQUENCE 


a5 
02 
02 
02 
30 
30 
06 
05 
30 
06 
05 
30 
06 
05 


is 


minimum number of length octets. 
length, 82, indicates that the length of the content is 


encoded in the next two octets. 


) 


82 
04 
01 
01 
2b 
Ob 
07 
00 
0d 
09 
00 
0d 
09 
00 


00 
52 
01 
02 


2b 


2b 


2b 


(in hexadecimal) as: 


39 


54 5d 76 


06 01 02 01 01 03 


06 01 02 01 04 16 01 02 


06 01 02 01 04 16 01 04 


not encoded using the 
(The first octet of the 


Case, McCloghrie, Rose £ Waldbusser 


[Page 17] 


RFC 1449 Transport Mappings 


9. Acknowledgements 

The UDP-based mapping is based, in 
The OSI-based mapping is based, in 
The DDP-based mapping is based, in 
Greg Minshall of Novell, Inc., and 


Computer, Inc. 


The IPX-based mapping is based, in 


for SNMPv2 


April 1993 


part, on RFC 1157. 


part, on RFC 1283. 


part, on earlier work by 
Mike Ritter of Apple 


part, on RFC 1298. 


The section on proxy to community-based SNMP is based on 
earlier work that was based in part on a suggestion by 


Jonathan Biggar of Netlabs, Inc. 


Finally, the comments of the SNMP version 2 working group are 


gratefully acknowledged: 


Beth Adams, Network Management Forum 
Steve Alexander, INTERACTIVE Systems Corporation 
David Arneson, Cabletron Systems 


Toshiya Asaba 

Fred Baker, ACC 

Jim Barnes, Xylogics, Inc. 
Brian Bataille 


Andy Bierman, SynOptics Communications, 
Uri Blumenthal, IBM Corporation 


Fred Bohle, Interlink 
Jack Brown 
Theodore Brunner, Bellcore 


Stephen F. Bush, GE Information Services 


Jeffrey D. Case, University of Tennessee, 


John Chang, IBM Corporation 
Szusin Chen, Sun Microsystems 
Robert Ching 


Chris Chiotasso, Ungermann-Bass 


Bobby A. Clay, NASA/Boeing 
John Cooke, Chipcom 
Tracy Cox, Bellcore 
Juan Cruz, Datability, Inc. 


David Cullerot, Cabletron Systems 


Cathy Cunningham, Microcom 


James R. (Chuck) Davin, Bellcore 


Michael Davis, Clearpoint 


Case, McCloghrie, Rose £ Waldbusser 


Knoxville 


[Page 18] 


RFC 1449 Transport Mappings for SNMPv2 April 1993 


Mike Davison, FiberCom 

Cynthia DellaTorre, MITRE 

Taso N. Devetzis, Bellcore 

Manual Diaz, DAVID Systems, Inc. 

Jon Dreyer, Sun Microsystems 

David Engel, Optical Data Systems 

Mike Erlinger, Lexcel 

Roger Fajman, NIH 

Daniel Fauvarque, Sun Microsystems 

Karen Frisa, CMU 

Shari Galitzer, MITRE 

Shawn Gallagher, Digital Equipment Corporation 
Richard Graveman, Bellcore 

Maria Greene, Xyplex, Inc. 

Michel Guittet, Apple 

Robert Gutierrez, NASA 

Bill Hagerty, Cabletron Systems 

Gary W. Haney, Martin Marietta Energy Systems 
Patrick Hanil, Nokia Telecommunications 
Matt Hecht, SNMP Research, Inc. 

Edward A. Heiner, Jr., Synernetics Inc. 
Susan E. Hicks, Martin Marietta Energy Systems 
Geral Holzhauer, Apple 

John Hopprich, DAVID Systems, Inc. 

Jeff Hughes, Hewlett-Packard 

Robin Iddon, Axon Networks, Inc. 

David Itusak 

Kevin M. Jackson, Concord Communications, Inc. 
Ole J. Jacobsen, Interop Company 

Ronald Jacoby, Silicon Graphics, Inc. 

Satish Joshi, SynOptics Communications, Inc. 
Frank Kastenholz, FTP Software 

Mark Kepke, Hewlett-Packard 

Ken Key, SNMP Research, Inc. 

Zbiginew Kielczewski, Eicon 

Jongyeoi Kim 

Andrew Knutsen, The Santa Cruz Operation 
Michael L. Kornegay, VisiSoft 

Deirdre C. Kostik, Bellcore 

Cheryl Krupczak, Georgia Tech 

Mark S. Lewis, Telebit 

David Lin 

David Lindemulder, AT&T/NCR 

Ben Lisowski, Sprint 

David Liu, Bell-Northern Research 


Case, McCloghrie, Rose & Waldbusser [Page 19] 


RFC 1449 Transport Mappings for SNMPv2 April 1993 


John Lunny, The Wollongong Group 

Robert C. Lushbaugh Martin, Marietta Energy Systems 
Michael Luufer, BBN 

Carl Madison, Star-Tek, Inc. 

Keith McCloghrie, Hughes LAN Systems 

Evan McGinnis, 3Com Corporation 

Bill McKenzie, IBM Corporation 

Donna McMaster, SynOptics Communications, Inc. 
John Medicke, IBM Corporation 

Doug Miller, Telebit 

Dave Minnich, FiberCom 

Mohammad Mirhakkak, MITRE 

Rohit Mital, Protools 

George Mouradian, AT&T Bell Labs 

Patrick Mullaney, Cabletron Systems 

Dan Myers, 3Com Corporation 

Rina Nathaniel, Rad Network Devices Ltd. 

Hien V. Nguyen, Sprint 

Mo Nikain 

Tom Nisbet 

William B. Norton, MERIT 

Steve Onishi, Wellfleet Communications, Inc. 
David T. Perkins, SynOptics Communications, Inc. 
Carl Powell, BBN 

Ilan Raab, SynOptics Communications, Inc. 
Richard Ramons, AT&T 

Venkat D. Rangan, Metric Network Systems, Inc. 
Louise Reingold, Sprint 

Sam Roberts, Farallon Computing, Inc. 

Kary Robertson, Concord Communications, Inc. 
Dan Romascanu, Lannet Data Communications Ltd. 
Marshall T. Rose, Dover Beach Consulting, Inc. 
Shawn A. Routhier, Epilogue Technology Corporation 
Chris Rozman 

Asaf Rubissa, Fibronics 

Jon Saperia, Digital Equipment Corporation 
Michael Sapich 

Mike Scanlon, Interlan 

Sam Schaen, MITRE 

John Seligson, Ultra Network Technologies 

Paul A. Serice, Corporation for Open Systems 
Chris Shaw, Banyan Systems 

Timon Sloane 

Robert Snyder, Cisco Systems 

Joo Young Song 


Case, McCloghrie, Rose & Waldbusser [Page 20] 


RFC 1449 Transport Mappings for SNMPv2 April 


Case, 


Roy Spitier, Sprint 

Einar Stefferud, Network Management Associates 
John Stephens, Cayman Systems, Inc. 

Robert L. Stewart, Xyplex, Inc. (chair) 

Kaj Tesink, Bellcore 

Dean Throop, Data General 

Ahmet Tuncay, France Telecom-CNET 

Maurice Turcotte, Racal Datacom 

Warren Vik, INTERACTIVE Systems Corporation 
Yannis Viniotis 

Steven L. Waldbusser, Carnegie Mellon Universitty 
Timothy M. Walden, ACC 

Alice Wang, Sun Microsystems 

James Watt, Newbridge 

Luanne Waul, Timeplex 

Donald E. Westlake III, Digital Equipment Corporation 
Gerry White 

Bert Wijnen, IBM Corporation 

Peter Wilson, 3Com Corporation 

Steven Wong, Digital Equipment Corporation 
Randy Worzella, IBM Corporation 

Daniel Woycke, MITRE 

Honda Wu 

Jeff Yarnell, Protools 

Chris Young, Cabletron 

Kiho Yum, 3Com Corporation 


McCloghrie, Rose & Waldbusser [Page 


1993 


21] 


RFC 


10. 


[1] 


[2] 


[3] 


[4] 


[5] 


[6] 


[7] 


[8] 


[9] 


[10] 


1449 Transport Mappings for SNMPv2 April 1993 


References 


Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 
"Protocol Operations for version 2 of the Simple Network 
Management Protocol (SNMPv2)", RFC 1448, SNMP Research, 
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., 
Carnegie Mellon University, April 1993. 


Postel, J., "User Datagram Protocol", STD 6, RFC 768, 
USC/Information Sciences Institute, August 1980. 


Information processing systems - Open Systems 
Interconnection - Transport Service Definition, 
International Organization for Standardization. 
International Standard 8072, (June, 1986). 


Information processing systems - Open Systems 
Interconnection - Transport Service Definition - Addendum 
1: Connectionless-mode Transmission, International 
Organization for Standardization. International Standard 
8072/AD 1, (December, 1986). 


G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk 
(second edition). Addison-Wesley, 1990. 


Waldbusser, S., "AppleTalk Management Information Base", 
RFC 1243, Carnegie Mellon University, July 1991. 


Network System Technical Interface Overview. Novell, 
Inc, (June, 1989). 


Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple 
Network Management Protocol", STD 15, RFC 1157, SNMP 
Research, Performance Systems International, MIT 
Laboratory for Computer Science, May 1990. 


Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 
"Coexistence between version 1 and version 2 of the 
Internet-standard Network Management Framework", RFC 
1452, SNMP Research, Inc., Hughes LAN Systems, Dover 
Beach Consulting, Inc., Carnegie Mellon University, April 
1993. 


McCloghrie, K., and Galvin, J., "Party MIB for version 2 
of the Simple Network Management Protocol (SNMPv2)", RFC 


Case, McCloghrie, Rose £ Waldbusser [Page 22] 


RFC 1449 Transport Mappings for SNMPv2 April 1993 


[11] 


1447, Hughes LAN Systems, Trusted Information Systems, 
April 1993. 


Information processing systems - Open Systems 
Interconnection - Specification of Basic Encoding Rules 
for Abstract Syntax Notation One (ASN.1), International 
Organization for Standardization. International Standard 
8825, (December, 1987). 


Case, McCloghrie, Rose & Waldbusser [Page 23] 


RFC 1449 Transport Mappings for SNMPv2 April 1993 


11. Security Considerations 


Security issues are not discussed in this memo. 
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